🥅 Successfully parse invalid response code data#614
Merged
Conversation
191d716 to
1efb90e
Compare
Collaborator
Author
|
@hoffi This is follow-up to #601/#597, and addresses #601 (comment). I intend to release this with v0.6.4. Some might see this as a "backward incompatibility" (as described the PR description). But, in my opinion, this is a bugfix and I don't intend to put this behavior behind a config flag. Let me know if you think otherwise. |
4e5be14 to
3c64122
Compare
When the parser encounters a recoverable error in `resp-text-code`, it
now returns `InvalidParseData` to represent the data that we've skipped
over. `InvalidParseData` can be used for similar recoverable parse
errors in the future (for example, many servers respond with invalid
`BODYSTRUCTURE` or incorrectly escaped quoted strings).
The specific example I have encountered the most is when Microsoft's
IMAP servers send an invalid COPYUID response code. Although it is
invalid for `resp-code-copy`, it's still a valid `resp-text-code`
because it does match `atom [SP 1*<any TEXT-CHAR except "]">]`.
This creates some minor differences for invalid `resp-text-code` data:
* <= v0.6.2: raises ResponseParseError (this is a bug).
* == v0.6.3: returns ResponseText with no ResponseCode (also a bug).
* >= v0.6.4: returns ResponseText with code with InvalidParseData.
Although this is a bugfix, it has a minor incompatibility for response
handlers which assume that a particular `ResponseCode#name` always
results in the same type of `ResponseCode#data`.
```ruby
# It was previously safe to assume the class of #data, based on #name:
imap.add_response_handler do |resp|
if resp in {data: {code: {name: "COPYUID", data: opyuid}}}
copyuid => Net::IMAP::CopyUIDData
end
end
# With this change, ResponseCode#data could also be InvalidParseData
imap.add_response_handler do |resp|
if resp in {data: {code: {name: "COPYUID", data: copyuid}}}
copyuid => Net::IMAP::CopyUIDData | Net::IMAP::InvalidParseData
end
end
```
Prior to v0.6.3, these responses would raise a ResponseParseError and
the response handler would not have been called.
3c64122 to
7f0e115
Compare
Contributor
|
@nevans yes this looks fine for me. 👍 Personally I do appreciate it that the response code contains a hint that the response contained data that could not be parsed properly so I could maybe handle this case individually. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When the parser encounters a recoverable error in
resp-text-code, it now returnsInvalidParseDatato represent the data that we've skipped over.InvalidParseDatacan be used for similar recoverable parse errors in the future (for example, many servers respond with invalidBODYSTRUCTUREor incorrectly escaped quoted strings).The specific example I have encountered the most is when Microsoft's IMAP servers send an invalid COPYUID response code. Although it is invalid for
resp-code-copy, it's still a validresp-text-codebecause it does matchatom [SP 1*<any TEXT-CHAR except "]">].This creates some minor differences for invalid
resp-text-codedata:<= v0.6.2: raises ResponseParseError (this is a bug).== v0.6.3: returns ResponseText with no ResponseCode (also a bug).>= v0.6.4: returns ResponseText with code with InvalidParseData.Although this is a bugfix, it has a minor incompatibility for response handlers which assume that a particular
ResponseCode#namealways results in the same type ofResponseCode#data.Prior to v0.6.3, these responses would raise a ResponseParseError and the response handler would not have been called.
I've updated the
ResponseCoderdoc with the following, even broader declaration: